比率|传统_Skywalking全链路追踪使用说明

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Skywalking全链路追踪使用说明相关的知识，希望对你有一定的参考价值。

        随着业务规模的不断增大&＃xff0c;系统的复杂度也越来越高&＃xff0c;我们的软件架构也进入了分布式的阶段&＃xff0c;服务按照不同的维度进行拆分&＃xff0c;那么一次请求可能横跨多个服务模块、项目&＃xff0c;依赖的中间件也越来越多&＃xff0c;其中任何一个节点出现异常&＃xff0c;都可能导致业务出现波动或者异常。而传统的日志监控等方式无法很好满足调用链路跟踪&＃xff0c;排查问题等需求&＃xff0c;这就导致定位/诊断服务异常变得异常复杂。

        因此面对复杂的调用链路&＃xff0c;我们需要一款全链路追踪工具&＃xff0c;帮助我们实现如下功能&＃xff0c;提高我们对业务的掌控度&＃xff1a;

&＃xff08;1&＃xff09;功能性需求&＃xff1a;

• ① 请求链路追踪&＃xff0c;快速定位故障&＃xff0c;缩短故障的排除时间 以及 判断故障影响范围
• ② 可视化链路各阶段的耗时&＃xff0c;进行性能分析&＃xff0c;排除业务瓶颈
• ③ 梳理服务依赖关系以及优化依赖的合理性
• ④ 系统指标监控&＃xff0c;吞吐量&＃xff08;TPS&＃xff09;、响应时间及错误记录等。

&＃xff08;2&＃xff09;非功能性需求&＃xff1a;

• 探针的性能消耗&＃xff1a;服务调用埋点本身会带来性能损耗&＃xff0c;这就需要组件对业务系统的性能影响小
• 代码的侵入性&＃xff1a;对业务系统尽可能少入侵或者无入侵其他&＃xff0c;对于使用方透明&＃xff0c;减少开发人员的负担。

        skywalking 是一个优秀的国产开源APM组件&＃xff0c;是一个对 Java 分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。2015年由个人吴晟开源 &＃xff0c; 2017年加入Apache孵化器。短短两年就被Apache收入麾下&＃xff0c;实力可见一斑。

        skywalking 支持 SpringBoot、SpringCloud、dubbo 集成&＃xff0c;代码无侵入&＃xff0c;通信方式采用 GRPC&＃xff0c;性能较好&＃xff0c;实现方式是 Java 探针&＃xff0c;支持告警&＃xff0c;支持JVM监控&＃xff0c;支持全局调用统计等等&＃xff0c;功能较完善。

3.1、仪表盘&＃xff1a;

        仪表盘是Skywalking的首页&＃xff0c;它提供多个指示板来可视化指标&＃xff0c;例如&＃xff1a;服务(APM)、数据库&＃xff08;Database&＃xff09;等等。

3.1.1、APM&＃xff08;服务&＃xff09;&＃xff1a;

        APM面板总体分为四个维度&＃xff1a;Global&＃xff08;全局&＃xff09;、Service&＃xff08;服务&＃xff09;、Instance&＃xff08;实例&＃xff09;、Endpoint&＃xff08;API&＃xff09;&＃xff0c;提供筛选功能&＃xff0c;每块都包含一些指标。

&＃xff08;1&＃xff09;Global&＃xff08;全局&＃xff09;指标&＃xff1a;

• Services Load&＃xff1a;服务每分钟请求数
• Slow Services&＃xff1a;慢响应服务&＃xff0c;按响应时间排序topN&＃xff0c;单位ms
• Un-Health Services (Apdex)&＃xff1a;Apdex性能指标&＃xff0c;即服务的不健康值&＃xff0c;1为满分&＃xff0c;Apdex是根据设定的阈值和响应时间综合考虑的衡量标准&＃xff0c;是满意响应时间和不满意响应时间相对于总响应时间的比率&＃xff0c;衡量的是用户对服务的满意程度&＃xff0c;因为传统的指标&＃xff08;如平均响应时间&＃xff09;可能很快就会容易形成偏差。
• Slow Endpoints&＃xff1a;慢接口平均响应耗时排序&＃xff0c;单位ms
• Global Response Latency&＃xff1a;响应时间百分比&＃xff0c;不同百分比的延时时间&＃xff0c;单位ms。percentile 标签含义&＃xff0c;例如 p99 为 3500ms&＃xff0c;意味着 99% 的请求应该比 3500ms 更快
• Global Heatmap&＃xff1a;服务响应时间热力分布图&＃xff0c;根据时间段内不同响应时间的数量显示颜色深度, 颜色越深&＃xff0c;请求越多。

&＃xff08;2&＃xff09;Service&＃xff08;服务&＃xff09;维度&＃xff1a;

• Service Apdex 数字&＃xff1a;Apdex性能指标
• Service Apdex 折线图&＃xff1a;一段时间的Apdex分数
• Service Avg Response Time&＃xff1a;服务平均响应时间
• Service Response Time Percentile&＃xff1a;百分比响应延时
• Successful Rate&＃xff08;%&＃xff09;数字&＃xff1a;请求成功率
• Successful Rate&＃xff08;%&＃xff09;折线图&＃xff1a;一段时间的请求成功率
• Service Load&＃xff08;CPM - calls per minute&＃xff09;&＃xff1a;每分钟调用数
• Service Load&＃xff08;CPM - calls per minute&＃xff09;&＃xff1a;一段时间的每分钟调用数
• Service Instances Load&＃xff08;CPM - calls per minute&＃xff09;&＃xff1a;每个实例每分钟请求数
• Slow Service Instance&＃xff1a;每个服务实例平均延时topN
• Service Instance Successful Rate&＃xff1a;服务实例的请求成功率 topN

 &＃xff08;3&＃xff09;Instance&＃xff08;实例&＃xff09;维度&＃xff1a;

• Service Instance Load&＃xff1a;实例每分钟调用数
• Service Instance Successful Rate&＃xff1a;实例调用成功比率
• Service Instance Latency&＃xff1a;实例响应延时
• JVM CPU&＃xff08;Java Service&＃xff09;&＃xff1a;JVM 占用 CPU 百分比
• JVM Memory &＃xff08;Java Service&＃xff09;&＃xff1a;JVM内存占用大小&＃xff0c;包含四个指标 instance_jvm_memory_heap&＃xff08;堆内存使用&＃xff09;、instance_jvm_memory_heap_max&＃xff08;最大堆内存&＃xff09;、instance_jvm_memory_noheap&＃xff08;直接内存当前使用&＃xff09;、instance_jvm_memory_noheap_max&＃xff08;最大直接内存&＃xff09;
• JVM GC Time&＃xff1a;JVM垃圾回收时间&＃xff0c;包含 young gc 和 old gc
• JVM GC Count&＃xff1a;JVM垃圾回收次数&＃xff0c;包含 young gc count 和 old gc count

&＃xff08;4&＃xff09;Endpoint&＃xff08;API&＃xff09;维度&＃xff1a;

• Endpoint Load in Current Service&＃xff1a;每个API每分钟请求数
• Slow Endpoints in Current Service&＃xff1a;平均响应时间的最慢的topN个API
• Successful Rate in Current Service&＃xff1a;每个API的请求成功率
• Endpoint Load&＃xff1a;当前API每个时间段的请求数据
• Endpoint Avg Response Time&＃xff1a;当前API每个时间段的平均响应时间
• Endpoint Response Time Percentile&＃xff1a;当前API每个时间段的响应时间占
• Endpoint Successful Rate&＃xff1a;当前API每个时间段的请求成功率

3.1.2、Database&＃xff08;数据库&＃xff09;&＃xff1a;

• Database Avg Response Time&＃xff1a;当前数据库平均响应时间
• Database Access Successful Rate&＃xff1a;当前数据库访问成功率
• Database Traffic&＃xff1a;当前数据库每分钟请求数
• Database Access Latency Percentile&＃xff1a;数据库不同响应时间占比
• Slow Statements&＃xff1a;当前数据库慢查询TopN
• All Database Loads&＃xff1a;所有数据库中请求量排序
• Un-Health Databases&＃xff1a;所有数据库不健康排名&＃xff0c;请求成功率排名&＃xff0c;失败最多的请求在最上。

3.2、拓扑图&＃xff1a;

        拓扑图可以很直观地展示服务与服务之间的依赖关系&＃xff0c;这对于我们进行服务梳理是非常有帮助的&＃xff0c;并且支持自定义分组&＃xff0c;如下图所示&＃xff0c;就将 ai-search、social-search、social-scan 三个服务自定义一个分组&＃xff0c;并通过拓扑图很直观地展示出三者间的依赖关系&＃xff1a;

        除此之外&＃xff0c;拓扑图还能查看服务运行信息进行度量&＃xff0c;包括开发框架类型、服务平均响应时间、吞吐量、百分比响应、Apdex分值、SLA值等

3.3、链路追踪&＃xff1a;

        链路追踪可以查看每个接口的调用链&＃xff0c;每个链路耗时、状态&＃xff0c;如果为失败&＃xff0c;还会展示错误信息&＃xff0c;如果是数据库也会展示查询语句&＃xff0c;如果是Redis还会展示操作指令&＃xff0c;另外可以根据追踪id&＃xff08;trace id&＃xff09;进行筛选查询&＃xff1a;

查看数据库操作详情&＃xff1a;

查看Redis缓存操作详情&＃xff1a;

3.4、性能剖析&＃xff1a;

        Skywalking 在性能剖析方面非常强大&＃xff0c;提供到基于堆栈的分析结果&＃xff0c;能够让开发人员一看看出调用过程中各个步骤所消耗的时间&＃xff0c;以便进行有针对性的进行优化。

        性能剖析通过新建任务&＃xff0c;对不同端点进行采样&＃xff0c;提供更详细的报告&＃xff0c;比如比链路追踪多了线程栈的信息、慢方法提示等等内容。接下来我们就介绍下怎么进行性能剖析&＃xff1a;

&＃xff08;1&＃xff09;新建任务&＃xff1a;

在 性能剖析模块 -> 新建任务 -> 选择服务、填写端点、监控时间&＃xff0c;操作如下图&＃xff1a;

备注&＃xff1a;每个服务&＃xff0c;相同时间只能添加一个任务&＃xff0c;且添加的任务不能更改也不能删除&＃xff0c;只能等待过期后自动删除

&＃xff08;2&＃xff09;执行请求&＃xff1a;

多次访问 "/api/searchByWholeOcr" 接口&＃xff0c;然后选择这个任务将会出现监控到的数据&＃xff0c;如下图&＃xff1a;

备注&＃xff1a;需要连续执行多次请求&＃xff0c;因为存在采用设置。如果执行次数少&＃xff0c;可能不会出现采样数据&＃xff0c;也就无法进行分析了

&＃xff08;3&＃xff09;性能剖析&＃xff1a;

        上图可以看出&＃xff0c;”/api/searchByWholeOcr“ 接口耗费了681ms&＃xff0c;通过分析详细堆栈信息&＃xff0c;我们可以看到耗时最多的操作就是SearchServiceImpl 类的 executeSearchRequest()方法&＃xff0c;耗费了563ms&＃xff0c;主要是调用 ES 做了全文搜索&＃xff0c;如下图所示&＃xff1a;